…avaArtifactsIT pass

JDT.LS was launched with -Xmx512m, which OOMs ("Java heap space") while indexing
the full platform classpath (~1000+ entries), killing the language server and with
it completion / auto-import / code actions. Make the max heap configurable via
DIRIGIBLE_JAVA_LSP_MAX_HEAP (DirigibleConfig.JAVA_LSP_MAX_HEAP) and default it to 2g.

Test framework: CreateJavaArtifactsIT now drives the nested New → Java → <item>
context menu reliably. Replaced the strict hover/visibility approach (which cannot
reach a collapsed 3rd-level submenu in headless Chrome, where moveToElement does not
fire mouseenter) with Browser.clickCascadingMenuItem, which scopes to the open
context menu and drives its own Angular mouseenter/click handlers in a single
in-frame script. Verified: the IT passes end to end (package folders, package
declarations and strong-interface skeleton signals all asserted over the workspace
REST API).

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

…mpletion

- Completion now propagates JDT.LS's isIncomplete so Monaco re-queries as you type
  (fixes the first Ctrl+Space showing nothing), and forwards the real trigger
  kind/character plus filterText/preselect/commitCharacters for correct filtering.
- Registered a Monaco editor opener: Go to Definition / Find References to a symbol
  in another workspace file now opens that file in the IDE and reveals the line
  (the single-file editor previously had no model for other files, so navigation
  silently did nothing). Same-file targets still jump within the editor.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

… file

Renaming a Java symbol (F2) now applies JDT.LS's full rename WorkspaceEdit across the
whole workspace instead of only the current file:

- Text edits in every referencing file are applied and persisted (read-modify-write
  over the workspace REST API, CSRF-guarded); the current file goes through the live
  Monaco model + save.
- RenameFile operations are honoured, so renaming a public class/interface/enum also
  renames its .java file and updates all references; when that file is the one being
  edited, the editor tab switches to the new file.
- Other open editors reload the changed files (dirty editors are skipped to avoid
  clobbering unsaved work) via a new monaco.file.reload topic.

Falls back to current-file-only rename if the IDE persistence hook is unavailable.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

…s, semantic colors, CodeLens, override/implement, keywords

Adds JDT.LS-backed language features to the Monaco Java editor:

Navigation & structure:
- Outline / breadcrumbs / sticky scroll (documentSymbol), code folding
  (foldingRange), occurrence highlight (documentHighlight), Go to Implementation
  and Go to Type Definition (reusing the cross-file editor opener), Format
  Selection (rangeFormatting) and Smart Expand Selection (selectionRange).

Editor intelligence:
- Inlay hints (parameter names + inferred types) and semantic-token highlighting
  (legend captured from the initialize result; semanticHighlighting enabled on the
  editor).
- CodeLens with "N references / N implementations" (click opens the peek).
- Override/Implement Methods wired into the existing member-picker generate flow.
- Always-available Java keyword completion, ranked below SDK/LSP results.

Advertises the matching client capabilities and enables the JDT.LS inlay-hint and
references/implementations CodeLens settings. All are additive providers; the exact
JDT.LS command ids are guarded.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

…yword colors

- Find/Peek References (and go-to-definition/implementation/type-definition) now
  create in-memory models for the referenced files, so the peek shows a real code
  preview instead of only file/line/column.
- Flush the pending debounced didChange before a completion request, so JDT.LS sees
  the just-typed text on the first Ctrl+Space (previously the first invocation
  completed against stale content and only the second worked).
- Revert the forced semanticHighlighting flag: JDT.LS emits keyword/modifier
  semantic tokens the vs-dark-based themes don't style, which left Java keywords
  uncolored. The semantic-tokens provider stays registered (inert until a theme opts
  in) so basic Monarch keyword coloring is restored.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

…e after rename

Root cause of "no quick-fixes / no Implement Methods / Generate toString does nothing":
- We advertised the *PromptSupport extended capabilities, so JDT.LS returned source
  actions (generate toString/constructors/accessors, override/implement, organize
  imports) as client-side "java.action.*Prompt" commands that the vscode-java
  extension implements but we don't — and the server commands we tried to call
  (checkToStringStatus/generateToString/…) don't exist on JDT.LS. Dropping those
  flags makes JDT.LS return the same actions as resolvable WorkspaceEdits (all
  members), which applyCodeAction resolves and applies directly.
- Code-action requests sent diagnostics reconstructed from Monaco markers, which lose
  the LSP code/data JDT.LS matches quick-fixes against. We now keep the original
  published diagnostics per file and send the ones overlapping the request range, so
  "Add unimplemented methods", "Create field", etc. appear.

Also: the Projects view ignored file rename/move events, so after a class rename the
tree still showed the old file. It now reloads on platform.files.renamed/moved.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

…n completion)

Renaming a public type (F2) had two defects:
- When JDT.LS ordered the RenameFile before the text edit, the edit was keyed by the
  new URI; we wrote the old content (old type name) into the new file, producing
  "The public type X must be defined in its own file". Edits are now re-attributed to
  the on-disk (old) URI before applying, so the new file gets the new type name.
- After renaming on disk we never told JDT.LS, so it kept validating stale state until
  a page refresh and kept suggesting the old type name in completion. We now send
  textDocument/didClose for the renamed-away file and workspace/didChangeWatchedFiles
  (Deleted old / Created new / Changed edited) so the server re-indexes immediately —
  clearing the stale diagnostic and dropping the old name from completion.

This also removes the exception/fallback path that made the first Enter occasionally
apply only the in-editor edit without renaming the file.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

- Cap JDT.LS completion at maxResults=50 so import/type suggestions over the large
  platform classpath return faster.
- On a Java file rename, the Projects view now renames the matching tree node in place
  and selects it (keeping it revealed) instead of doing a full collapse-reload, so the
  renamed file stays visible and highlighted; falls back to a reload if the node isn't
  loaded.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

…meter to field)

Set the Monaco code-action lightbulb to "on" so it appears whenever any code action is
available at the cursor — not only on diagnostics. This surfaces JDT.LS refactor
assists like "Assign parameter to new field" / "Assign all parameters to new fields"
(kind refactor.assign.field) on a constructor parameter, plus Extract Method/Variable/
Constant/Field, as a visible suggestion instead of being hidden behind Refactor…. The
assist itself already flowed through the existing code-action provider.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

…ce CodeLens

The Java editor had become slow to "enable" features on a fresh project and sluggish
while typing. Two avoidable load sources, on top of JDT.LS's inherent cold-start
indexing of the large platform classpath:

- Code-action requests omitted triggerKind, so JDT.LS computed the full set of quick
  assists/refactorings on every passive-lightbulb evaluation (every cursor move). Now
  we forward Monaco's trigger (Invoke=1/Auto=2, 1:1 with the LSP kind): the passive
  lightbulb computes only quick-fixes (cheap); full assists/refactorings only on
  explicit Ctrl+. / Refactor….
- references/implementations CodeLens ran a reference search for every declaration on
  open and on every edit — the heaviest always-on provider. Disabled by default.
- Reverted the eager `lightbulb: 'on'` (its purpose was to surface refactor assists in
  the passive bulb, which we instead keep on the explicit Refactor… surface).

Refactor assists like "Assign parameter to new field" / Extract remain available via
Refactor… (Ctrl+Shift+R).

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

…ling / CreateNewFileIT)

BlimpKit's context menu disables scrolling for any submenu that contains a nested
submenu (contextmenu.js canScroll). Nesting the "Java" group inside "New" therefore
turned off scrolling for the whole New menu, so once enough artefact templates are
registered the menu overflows the viewport and top items (e.g. "JavaScript Service")
become unreachable — which failed CreateNewFileIT.

Move "Java" to a top-level context-menu entry (sibling of New) on project/folder
nodes. New keeps its scrolling; "Java" is its own 2-level submenu. Workbench page
object navigates Java → <item> accordingly. Verified: CreateNewFileIT and
CreateJavaArtifactsIT both pass.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

…ath; index freshness

The Java editor was slow to "enable" features after every jar restart because JDT.LS
re-indexed the whole platform classpath each time. Causes and fixes:

- JdtLsManager wiped the JDT.LS data/index dir on every start. Since ClassPathIndex
  now extracts to a stable cache dir, the index only goes stale when the classpath
  actually changes. Wipe is now guarded by a classpath fingerprint (SHA-256 of the
  sorted classpath entries) stored next to the data dir: matching fingerprint → reuse
  the index (warm, fast restart); mismatch/first run → rebuild once.
- Pre-warm the (cached) compile classpath on the boot virtual thread so the first Java
  file open doesn't pay the multi-second materialisation.
- After didOpen, send workspace/didChangeWatchedFiles(Created) so JDT.LS's project
  model includes just-created files immediately (a fresh interface is now offered in a
  sibling class without waiting for a rebuild).
- Dropped java.completion.maxResults (it equalled JDT.LS's default and only risked
  trimming relevant results such as the project's own types).

Verified: CreateJavaArtifactsIT + CreateNewFileIT pass; logs show "Pre-warmed compile
classpath" and the fingerprint-guarded "Building/Reusing JDT.LS index".

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>